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REMARKS 

The Office Action and the references cited therein have been carefully considered. 
Claims 1-42 are pending, remain pending, and are at issue herein. Claim 27 has been 
indicated as objected to as being dependent upon a rejected base claim, but otherwise allowable. 

Claims 1, 27 and 31 have been amended to correct typographical errors. Specifically, 
claim 1 has been amended to correct an antecedent basis. Claim 27 has been amended to 
remove a duplicate word. Claim 31 has been amended to correct its dependency. These 
amendments do not narrow the scope of the claims in any way. 

The Examiner has rejected claim 31 under 35 U.S.C. § 1 12, second paragraph as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which Applicants regard as the invention. Claim 31 has been amended to depend from claim 
30. This amendment to claim 31 is believed to overcome the Examinees rejection and it is 
respectfully requested that the Examiner withdraw this rejection of claim 31. 

The Examiner has rejected claims 1, 4-6, 8-11, 15-18, 23, 25-26, 28-30, 34, and 36-42- 
under 35 U.S.C. § 102(b) as being anticipated by Allran (U.S. Patent No. 5,630,132). The 
Applicant respectfully traverses this ground of rejection. Reconsideration of this rejection in 
view of the following comments is respectfully solicited. 

With respect to claim 1, the steps of commanding an object to set a first data type on 
the input of the object, to set a second data type on the output, to process data of the first type 
received at the input of the object and to generate output data of the second type at the output 
of the object are required. Applications use objects to manipulate data by commanding the 
object to process data in the format the application selects and which an object supports. As 
explained in the instant application, an application has the capability to determine the media 
types (i.e., data format) that an input of an object can accept and the media types that an 
object can output. The minimum size of an object's input and output buffer sizes can be 
found so that the minimum size of input and output buffers can be used to guarantee that 
some data is processed. Applications set the input and output media types of an object, 
directly control when an object processes input data or generates output data, and knows the 
media types an object supports by having objects enumerate their capabilities. 
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The Examiner refers to column 16 lines 1 1, 28-29, 22-23, and 26 and FIG. 13 of 
Allran and states that Allran teaches the steps of claim 1. The Applicants respectfully 
disagree. FIG. 13 of Allran is a block diagram representation of the multiplexing of audio 
output signals from modular multimedia software tasks to a CD-digital-to-analog converter 
and speakers through the use of a virtual data communication module 317 and data 
communication modules 301, 303, 305, 309, 311 of Allran. 

Allran teaches a data processing system for executing multimedia applications that 
interface with multimedia devices that consume or produce real-time and asynchronous 
streamed data. The system includes a CPU for execution of multimedia applications and a 
digital signal processor (DSP) for processing data. Tasks are called by the multimedia 
application for execution in the DSP. The tasks of Allran represent operations that are 
performed on the data, which is consumed or produced by multimedia end devices or other 
tasks. The tasks are linked with other selected tasks and selected multimedia devices via data 
communication modules. A DSP manager is resident in the CPU and monitors resource 
allocation to allow a software task to be loaded and executed while at least one other software 
task is being executed by the DSP without interference with execution. Allran has been 
thoroughly reviewed and no teaching or suggestion of setting a data type on the input or the 
output of a task could be found. Additionally, no commands could be found in Allran to 
command the task to process data or generate output data. 

The data communication modules of Allran have "rigid data communication 
structures and standardized data communication protocols" and are used to pass data from 
one task to another task. No processing is performed on the data by the data communication 
modules. The preferred embodiment of the data communication modules of Allran are 
circular buffers or memory arrays which are used to pass data streams between two or more 
tasks or between one task and one or more end devices. One task is designated as the 
"owner" of any particular data communication module and the owner is the only task that is 
allowed to write to the circular buffer. User tasks read from the circular buffer. Four 
standardized communication protocols that are selected by a user are taught for use with data 
communication modules. They are a synchronous protocol (owner task writes data to circular 
buffer at a constant rate and a user task reads data at the same constant rate), an owner data 
driven protocol (owner task writes to circular buffer open-loop at its own rate and a user task 
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is expected to keep up with owner task), a user data driven protocol (user task reads data at its 
own rate and the owner task is expected to match the rate of user task), and a safe data driven 
protocol (owner task and user task actively prevent overrun through the use of pointers). It 
can be seen that the data communication modules of Allran are memory buffers or memory 
arrays and do not process data or generate output data. Therefore, there is no command to 
order the memory buffers or memory arrays to process data or generate output data. 
Additionally, since the data communication module is merely a buffer or memory array, there 
is no input or output and therefore, there is no command to set a data type on an input or on 
an output. 

The virtual data communication module of Allran sums inputs and provides the 
summed inputs as an output of the virtual data communication module. As soon as the 
virtual communication module receives inputs, it sums the inputs to produce the output. A 
mute task may be connected between data communication modules and a virtual data 
communication module to apply an attenuation or mute factor to the outputs of the data 
communication modules to prevent overflow of the summing operations. In the operation 
depicted in FIG. 13 of Allran, the virtual data communication module sums the outputs of the 
data communication modules that pass data from the synthesizer task, the modem audio task, 
and the alarm clock sound task. In order for a virtual data communication module to sum the 
outputs, it must receive the data simultaneously . As stated in Allran, the "use of the virtual 
data communication module allows the simultaneous driving of speakers with the real-time 
and/or asynchronous streamed data from those tasks." Since data of different data types is 
described that must be received simultaneously and output as a sum of all data types, it is 
respectfully submitted that there is no teaching or suggestion of commanding an object to set 
a data type on an input or on an output. Additionally, no teaching or suggestion could be 
found for a command to order the virtual data communication module to process data or 
generate output data. 

From the foregoing, it is respectfully submitted that Allran does not teach or suggest 
the steps of commanding an object to set a first data type on an input of the object, 
commanding the object to set a second data type on an output of the object, commanding the 
object to process data of the first type received at the input of the object, and commanding the 
object to generate output data of the second type at the output of the object. 
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It is therefore respectfully requested that the Examiner withdraw the 35 U.S.C. § 102 
rejection of claim 1. Claims 4-6 and 8-1 1 depend from claim 1 and are believed to be 
patentable for the same reasons set forth above for claim 1 . 

With respect to claims 8-9, Allran teaches at column 12, lines 18-30 that the size of 
the circular memory array is specified when a connection is defined. It is respectfully 
submitted that specifying the size of a circular memory array is not the same as querying an 
object for a minimum input buffer size required to guarantee that some data is processed 
when the object is commanded to process data of the first type or querying the object for a 
minimum output buffer size required to guarantee that some data is output when the object is 
commanded to generate output data. 

With respect to claim 10, Allran teaches at column 15, lines 37-57 the steps of reading 
data from a data communication module operating in the owner data driven protocol mode of 
operation or the safe data driven protocol mode of operation. It is respectfully submitted that 
the steps of reading data from a data communication module does not teach or suggest the 
steps of determining an first data type that the object can process on the input and 
determining a second data type that the object can support on the output. 

With respect to claim 1 1, the "empty" that Allran teaches refers to the DSP reading 
data from a circular memory array until all data from the circular memory array has been 
read. It is respectfully submitted that reading data from a circular memory array does not 
teach or suggest the step of informing an object that the data is discontinuous on the input of 
the object. 

In view of the foregoing, it is therefore respectfully requested that the Examiner 
withdraw the 35 U.S.C. § 102 rejection of claims 4-6 and 8-11. 

With respect to claim 1 5, it is an independent claim. The Examiner refers to the 
rejection of claim 1 and rejects claim 15 for the same reasons set forth for claim 1. Claim 15 
is believed to be patentable for the same reasons set forth above for claim 1. Claims 16-29 
depend from claim 15 or from claims depending from claim 15 and are believed to be 
patentable for the same reasons set forth for claim 15. 

With respect to claims 25-26, the Examiner refers to the Examiner's rejection of 
claims 8-9. Claims 25-26 are believed to be patentable for the same reasons set forth above 
for claims 8 and 9. Furthermore, claim 25 requires the step of setting a buffer flag that 
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indicates that a plurality of buffers may be held. Allran does not teach the use of flags as the 
Examiner states in paragraph 6 of the office action. Nor does Allran teach or suggest the use 
of a lookahead value as required by claim 26. 

With respect to claims 28 and 29, the present application teaches that new objects are 
registered in the operating system and in an exemplary embodiment, the objects are registered 
in the system registry of the operating system. The object registers the class ID under which 
the object is registered, the category of the object, whether a key is needed to use the object, 
and the number and data types of input and outputs of the object. Allran teaches the step of 
scheduling an existing task for execution by the DSP of Allran. It is respectfully submitted 
that scheduling a task for execution is not the same as registering an object nor does it 
suggest registering an object as required by claim 28. Column 27, lines 40-57 of Allran teach 
commands that instructs the digital signal processor to set aside memory for a particular task, 
that initialize the digital signal processor by clearing registers, resetting the processor, and 
loading the operating system, that loads a module of selected tasks, that instructs the digital 
signal processor to load the data segments and instruction segments which make up a single 
task, and that instructs the digital signal processor to load a single segment (that is, a small 
block of instructions and/or data). No teaching or suggestion could be found in Allran to 
identify a class ID, identify a category, identify whether a use is keyed, identify a number of 
input data types to register, identify the input data types, identify a number of output data 
types to register, and identify the output data types. 

In view of the foregoing, it is respectfully requested that the Examiner withdraw the 
rejection of claims 15-18, 23, 25-26, and 28-29. 

With respect to claim 30, it is an independent claim. The Examiner refers to the 
rejection of claim 1 and rejects claim 30 for the same reasons set forth for claim 1 . Claim 30 
is believed to be patentable for the same reasons set forth above for claim 1 . Claims 3 1 -42 
depend from claim 30 or from claims depending from claim 30 and are believed to be 
patentable for the same reasons set forth for claim 30. Additionally, claims 36-37 are 
believed to be patentable for the same reasons set forth above for claim 25 and 26. Claim 40 
is also believed to be patentable for the same reasons set forth above for claims 8 and 9. 
Claims 41 and 42 are also believed to be patentable for the reasons set forth above for claim 
10. 
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In view of the foregoing, it is respectfully requested that the Examiner withdraw the 
rejection of claims 30, 34, and 36-42. 

The Examiner has rejected Claims 2-3, 7, 12-14, 19-22, 24, 31-33, and 35 under 35 
U.S.C. § 103(b) as being unpatentable over Allran in view of Maas (U.S. Patent No. 6,092,128). 
The Applicants respectfiilly traverses this ground of rejection. Reconsideration of this rejection 
in view of the following comments is respectfully solicited. 

Claims 2-3, 7, and 12-14 depend from claim 1 and are believed to be patentable for 
the same reasons set forth above for claim 1 . Claims 19-22 and 24 depend from claim 15 and 
are believed to be patentable for the same reasons set forth above for claim 15. Claims 31-33 
and 35 depend from claim 30 and are believed to be patentable for the same reasons set forth 
above for claim 30. 

Additionally, the Examiner states that Allran does not teach the use of flags, that 
Maas teaches the use of status flags to control the flow of input and output streaming data in a 
data transmission environment, and that it would have been obvious to apply the teachings of 
Maas to the system of Allran because the flag controls the flow of data between the sources, 
therefore preventing overflow and underflow of data as disclosed by Maas. The Applicants 
respectfully disagree. Applicants respectfully submit that the Examiner's statement is a 
conclusory statement that is not allowed by in re Lee 61, USPQ2d 1430 (2002). 

Furthermore, to make a prima facie case of obviousness, the prior art reference or 
references must teach or suggest all of the claim limitations. The Examiner properly states 
that Allran does not teach the use of flags. Maas has been thoroughly reviewed. Maas 
teaches flags that are used to indicate when particular boundary conditions (such as full, 
empty, almost full, almost empty, overflow, underflow, etc.) are present, that data being read 
is invalid and may require recovery by another layer of an Ethernet protocol, and to indicate 
underflow and overflow conditions. 

Claim 2 requires the step of detecting when an incomplete status flag is set and re- 
commanding the object to generate output data if the incomplete status flag is set. Claim 3 
requires the step of re-commanding the object to generate output data for as long as the 
incomplete status flag is set. Claim 7 requires the step of waiting for the incomplete status 
flag to reset before performing the step of commanding the object to process data of the first 
type received at the input of the object. 
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It is respectfully submitted that neither Allran or Maas, singly or in combination, 
teach the steps of detecting when an incomplete status flag is set, re-commanding the object 
to generate output data if the incomplete status flag is set, re-commanding the object to 
generate output data for as long as the incomplete status flag is set, or waiting for the 
incomplete status flag to reset before performing the step of commanding the object to 
process data of the first type received at the input of the object. 

Claim 12 is also believed to be patentable for the same reasons (or for similar reasons) 
set forth above for claims 2-3, 7, 8 and 10-11. Claim 13 is also believed to be patentable for 
the same reasons (or for similar reasons) set forth above for claims 2-3, 7, 8, and 10-11. 
Claim 14 is also believed to be patentable for the same reasons (or for similar reasons) set 
forth above for claims 2-3. Additionally, no teaching or suggestion could be found in Allran 
or Maas, singly or in combination, for detecting that an output flag has been set to indicate 
that output data can be generated. 

Claims 19-20 are also believed to be patentable for the same reasons (or for similar 
reasons) set forth above for claims 2-3. Claim 21 is also believed to be patentable for the 
same reasons (or for similar reasons) set forth above for claim 8. Additionally, no teaching or 
suggestion could be found in Allran or Maas, singly or in combination, for buffering data 
internally when there is insufficient data to generate output data. 

Claim 22 is also believed to be patentable for the same reasons (or for similar reasons) 
set forth above for claims 2-3. Additionally, no teaching or suggestion could be found in 
Allran or Maas, singly or in combination, for providing an indication that output data can be 
generated. Claim 24 is also believed to be patentable for the same reasons (or for similar 
reasons) set forth above for claims 2 and 11. Additionally, no teaching or suggestion could 
be found in Allran or Maas, singly or in combination, for generating all data that can be 
processed in response to notice from the application that data is discontinuous on the input. 

Claims 3 1 and 32 are also believed to be patentable for the same reasons (or for 
similar reasons) set forth above for claims 2-3. Additionally, no teaching or suggestion could 
be found in Allran or Maas, singly or in combination, for issuing a reset status flag upon 
generating all output data for the associated input data. 
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Claim 33 is also believed to be patentable for the same reasons (or for similar reasons) 
set forth above for claims 2-3 and for claim 22. Claim 35 is also believed to be patentable for 
the same reasons (or for similar reasons) set forth above for claims 2, 1 1, and 24. 

Therefore, in view of the foregoing, it is respectfully submitted that the Examiner has 
not put forth a prima facie case of obviousness. It is therefore respectfully requested that the 
Examiner withdraw the 35 U.S.C. § 103 rejection of claims 2-3, 7, 12-14, 19-22, 24,31-33, 
and 35. 

The application is considered in good and proper form for allowance, and the 
Examiner is respectfully requested to pass this application to issue. If, in the opinion of the 
Examiner, a telephone conference would expedite the prosecution of the subject application, 
the Examiner is invited to call the undersigned attorney. 



Respectfully submitted, 




Kevin L. Wingate, Reg. Nfr. 38662 
LEYDIG, VOIT & MAYER, LTD. 
6815 Weaver Road, Suite 300 
Rockford, Illinois 61 1 14-8018 
(815)963-7661 (telephone) 
(815) 963-7664 (facsimile) 



Date: February 4, 2004 



